Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Thanks for the PR @pcwalton! I talked about something like this in the past with @wycats and the conclusion we've reached is that the specification here is probably best done at the top level, not in the dependencies themselves. In general it seems best if you have complete control over how your dependencies are built rather than having a transitive dependency deciding how it's compiled. One example of this is that the logic for "pick the highest level" isn't always correct as there may be some dependencies you want to force to a lower optimization level.

This issue about configuring dependencies from the top-level definitely comes up quite a bit (#1359, #629, #942), and it's probably best to enable solving all of these in basically one fell swoop. Along those lines I think that we'll want to implement something along the lines of:

[dependencies-config]
foo = { profile = "release" }
"bar:0.1.4" = { override = "path/to/override" }
"crates.io/foo" = { crate-type = [ "..." ] }

This allows you to:

• At the top level have control over how each dependency is compiled
• Reference existing profiles to leverage all the other options in profiles
• Specify any arbitrary package in the dependency graph unambiguously

Some of these details I think still need to be bike-shedded and this may warrant an RFC as well as it's a somewhat substantial change.

OK, I'll work on this ASAP. I am blocked on this so there is no other option.

☔ The latest upstream changes (presumably #1848) made this pull request unmergeable. Please resolve the merge conflicts.

This has been inactive for awhile (and I think Servo is working for now), so I'm going to close this in favor of issue like #942 which should provide a nice vector for us to implement this.